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Agenda 


This  presentation  will  cover 

■  Describe  how  the  views  are  related 

■  Identify  the  main  viewpoints  relevant  for  the  Enterprise  Architecture  and 
Systems  Engineering  phases  of  development 

■  Show  the  patterns  across  the  views  and  Viewpoints 

■  Discuss  a  generic  workflow 

■  Points  for  discussion  on  UPDM/SysML  modelling 
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DoDAF  2.0  Viewpoints 


■Capability  Viewpoint:-  Capture  the  capabilities  that  the  enterprise  is  expected 
to  realise  and  shows  how  they  are  deployed  to  organizations  (prefix  CV) 

Operational  Viewpoint:-  Contains  the  views  required  to  describe  the 
Operational  and  high  level  functional  aspects  of  the  architecture  (prefix  OV) 

Service  Viewpoint:-  Captures  the  views  required  to  specify  of  the  Services  (i.e. 
interface,  no  implementation)  required  to  support  the  Operational  objectives  of 
the  architecture  (prefix  SvcV) 
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DoDAF  2.0  Viewpoints 


■Systems  Viewpoint:-Captures  the  specification  of  the  Systems  that  are 
required  to  be  implemented  or  that  already  exist  that  help  achieve  the 
operational  objectives  (prefix  SV) 

Project  Viewpoint:-  Maps  the  enterprises  to  the  projects  and 
organisations  that  will  realise  the  capabilities  through  the  development  of 
systems  and  services  (prefix  PV) 
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DoDAF  2.0  Viewpoints 


Standards  Viewpoint:-Contains  all  the  information  relating  to  the 
standards  that  constrain  the  other  3  viewpoints  (prefix  by  StdV) 

■All  Viewpoint:-  Contains  the  summary  information  about  the  architecture 
being  developed  including  the  data  dictionary  (prefix  by  AV) 
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Model  Element  interaction  Across  Views 


Separation  of  Elements  and  Views/Viewpoints 

■  Some  elements  seen  in  multiple  views 

■  Some  views  ties  the  viewpoints  together  e.g.  SV-5 


Essential  Views  and  model  elements  based  upon  Initial  Guidelines  for  use;  NAF  3  VI. 0 


All  Views 

Capability  Views 

Operational  Views 

System  Views 

Service  Vie  ws 

Programme  Views 

Technical  Vie ws 
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View  and  Viewpoint  interrelationship ps 


■  The  Viewpoints  are  not 
independent  but  are  heavily 
interrelated 

■  Each  face  of  Cube 
represents  a  viewpoint 

■  Each  window  a  separate  view 
or  product 

■  Model  Elements  internal  to 
cube  used  by  multiple  views 

■  Views  can  act  as 


■  Filters  on  the  information 
in  the  architecture  (OV-3, 
SV-5) 

■  Diagrams  allowing  you  to 
create  the  information 
that  populates  the 
architecture  (SV-1,  OV-2) 


Capability  Views 


Operational  Views  ^ 
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Viewpoint 

relationships 

UPDM  DoDAF  is  a  set  of 
traceability  matrices 

■  Systems  and  Services 
support  and  implement 
Operational  elements 

■  Services  expose 
capabilities  (service  as 
an  interface) 

■  Operational  elements 
(activities)  map  to 
capabilities 

■  Capabilities  are 
delivered  by  Projects 

■  Systems  and  Services 
are  the  realized  by 
projects 

■  Everything  constrained 
by  standards 

These  relationships  are 
captured  in  the  various 
matrix  views 
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Data  and  Information  Viewpoint,  captures 
data  models  at  different  level  of  abstraction 


All  Viewpoint,  encompasses  summary  information 
and  all  data  definitions  in  the  architecture 
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Enterprise  View 
of  UPDM  DoDAF 

Used  by 

■  Planning 

■  JCIDS 

■  Operations 

■  Portfolio  management 

For 

■  Capability 
management 

■  Operations  Planning 

■  Develop  High  level 
requirements  for 
prime  suppliers 

Still  need  the 

■  All  view, 

■  Standards  view 

■  Parts  of  the  Data  and 
Information  view 
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Data  and  Information  Viewpoint,  captures 
data  models  at  different  level  of  abstraction 


All  Viewpoint,  encompasses  summary  information 
and  all  data  definitions  in  the  architecture 
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The  Systems 


Viewof  UPDM 

DoDAF 

Used  by 

■  Portfolio  management 

■  Operations  planning 

■  Defense  Acquisition 
System 

■  Systems  Engineering 
teams 

-  In  forces 

-  Primes/Tier  ones 

■  Provides 
requirements  to 
engineering  teams 

Still  need  the 

■  All  view, 

■  Standards  view 
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■  Parts  of  the  Data  and 
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All  Viewpoint,  encompasses  summary  information 
and  all  data  definitions  in  the  architecture 
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Key  relationships  for  Systems  Engineering 


•Resources  exchanged 


Patterns  in  the  Framework 


Capability 

Operational 


Systems 


Services 


Core  Views 
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SV-3/6 
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SvcV-1/2 


Structure  (IBDs) 


SvcV-4 


SvcV-3/6 


SvcV-5a 


Behaviour  (activity  based) 

Data  exchange  Summarys 
(Table/Matrix  views) 

Traceability  matrices 


Supporting  Views 
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SvcV-IOc 


Behaviour  (sequence  diagrams) 


Key  View  dependencies  for  systems  engineering 


•Source  where  element  is  shown 

•Target  where  the  element  is 
referenced  from 

•Dashed  lines  show  trace  references 

•Traceability  matrices  CV-6,  CV-7,  SV- 
5a/b,  SvcV  5 

•Structure  OV-2,  SV-1,  SVCV-1 
•Behaviour  OV-5,SV-4,ScvV-4 

•Sequence  Diagrams,  OV6,  SV- 
10c,  SvcV- 10c 


Environment 


•Info  exchanges  OV-3,SV-3/6,SvcV-3/6^^^ 


SV-5a/b 


SvcV- 

10c 


SvcV-4 
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High  level  workflow  (core) 


•Develop  capability  views 

•  Enterprise  visions 

•  Capability  hierarchy  and 
dependencies 

•Develop  Operational  views 

•  Behavior,  structure, 

•  Derive  data  exchange  matrices 

•  Trace  back  to  capabilities 

•Develop  systems/service 
views 

•  Behavior,  structure, 

•  Derive  data  exchange  matrices 

•  T race  back 

•  Systems  to  operations  that  they 
implement 

•  T race  back  Services  to  the 

•  Operations  they  support 

•  Capabilities  they  expose 
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The  generic  workflow  applied  to  the  OVs 


Step-1  BlackBox  behavior 


Step-3  Allocate  behavior 
to  structure  (WhiteBox) 
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The  generic  workflow  applied  to  the  OVs 


Step-3  Allocate  behaviour 
to  structure  (WhiteBox) 


Step-6  generate  OV-3  Information 
exchange  summary 
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Step-5  Define 
Information 
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Relating  UPDM  and  SysIVL  models  Discussion 

■  Handling  requirements 

■  In  UPDM  requirements  driven  from  the  level  above 

■  Non  functional  requirements  captured  as  constraints 

■  Also  work  with  Parametric  diagrams 

■  It  is  possible  to  import  requirements  into  UPDM  models  and  tie  them  to  Capabilities 

■  3  main  options 

■  Keep  SysML  models  as  part  of  UPDM  models 

■  Import  parts  of  UPDM  models  directly  into  a  SysML  model 

■  Reference  UPDM  elements  from  SysML  models 

■  Options  as  part  of  these  are 

■  Embed  SysML  elements  directly  in  the  UPDM  elements 

■  Ties  the  elements  too  closely  into  UPDM  but  I  think  there  will  be  issues 

■  Separate  out  SysML  models  and  trace  to  UPDM  elements 

■  Keep  to  the  patterns  in  UPDM  re  traceability  to  the  upper  levels 

■  4  th  option 

18  ■  Separate  UPDM  and  SysML  models  and  trace  through  third  party  tool  (i.e.  ©©©R9  ^ration  2012 


Relating  UPDM  and  SysIVL  models  Discussion 


■  Keep  SysML  models  as  part  of  UPDM  models 

■  Models  become  very  large  and  monolithic 

■  Hard  to  maintain  and  manage 
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Relating  UPDM  and  SysIVL  models  Discussion 

■  rlnnport  parts  of  UPDM  models  directly  into  a  SysML  model 

■  Evolve  the  model  with  SysML  elements 

■  End  up  with  separate  models 

■  Disconnect  between  the  high  level  specification  of  a  System  in  the  UPDM  model  and 
thejSysML 

■  Issues  with  the  need  to  maintain  consistency  between  the  views 

■  Issues  with  pushing  more  detail  up  into  the  UPDM  views  as  there  will  then  be 
inconsistency  in  the  detail  and  you  may  lose  relations/dependencies  to  the  elements  at 
the  higher  level 

B  Interchange  issue  as  you  are  replacing  elements  you  may  lose  ownership  of 
relationships  (might  be  OK  in  the  same  tool,  but  XMI  ?) 

■  Need  Diff-Merge  capability  for  XMI  ? 
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Relating  UPDM  and  SysIVL  models  Discussion 
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Reference  UPDM  elements  from  SysML  models 

■  Maintain  the  consistency  of  the  UPDM  model 

■  Maintain  the  patterns  of  the  UPDM  structure  in  the  SysML 
model 

■  Trace  between  SysML  and  UPDM  easily 

■  End  up  with  a  number  of  Branch  SysML  models  that 
reflect  the  lower  level  system  structure 

■  Cannot  use  the  UPDM  elements  as  they  are  read  only 
(Advantage) 

Initial  proposal 

■  Combination  of  taking  UPDM  models  by  reference  and 
importing  the  lower  levels  of  the  UPDM  architecture  and 
removing  UPDM  stereotypes 

■  Change  to  SysML  elements 

■  Trace  back  to  reference  elements 

■  Gives  the  possibility  of  reuse  and  also  shows  the 
reference  to  original  elements 
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Summary 


■  Brief  review  of  Viewpoints 

■  How  elements  are  related  across  the  viewpoints 

■  Identification  of  patterns  in  the  view  points 

■  Generic  Workflow 

■  UPDM  and  SysML 
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